Proceedings of The National Conference on Man Machine Interaction 2014 [NCMMI 2014] 



7 



Elaborating Operational Requirements from 

Goals 

C. Suganya, S. Thirumal 

Computer Science & Engineering Department, G.K.M College Of Engineering And Technology. 

Assistant Professor, Dept of Computer Science, G.K.M College Of Engineering And Technology .^^V 

Abstract — Requirement Engineering comprises of deriving stakeholders goals and their enhajweragfit into 
operational requirement specification .Insufficiency in the process of any of these task wjirV^Jl up with 
severe problem in the system development, it becomes expensive to recover. Here wiH^ntroS^uce a formal, 
efficient approach for generating requirements that satisfies the given stakeholda^^na'ls. Goal-based 
methods have progressively accepted in effect of eliciting, elaborating, analyzing^Hdjbecifying software 
requirements. We use a tool-based framework for combining model checkinlii^d inductive learning 
approach. The model checker applicably validates the goal satisfaction and (wgsies counterexample once 
incompleteness in the operational requirements are found. The Learner campures the requirements from 
positive and negative samples. These well-read requirements are reliabt^ytrj goals . This procedure is done 
iteratively till no goal destruction is identified. 



Keywords- Requirements specifications, elaboration, elicitation ^ptfiods, operational requirements, model 
checking, inductive learning. 

I. Introdi 

Requirement engineering concerned with the^Acrtation, elaboration, specification, analysis and 
documentation of goals and requirements to an eh^isaged system. It infers that organized and repeatable 
systems should be used to ensure that sysj/fi^equirements are comprehensive and reliable. When the 
execution of these methods encountered eitoneous process, it leads to severe development problem which 
is hard to repair. This leads to seek autcKnajea 1 method for the achievement of goal. This method targets to 
links the space among high level sy»aa gBals and low level system requirements. 



Goals are the targets, to be atlenVd by the system. The term 'system' here denotes to the software-to-be 
with the setting. OperatipngrtOTmrements prompt restrictions on the operation to be done by the system. 
The difficulty in the sysM^^Siiifelopment is the expansion of the operational requirements that guarantees 
the goal. If the manuaWrciqgJss is undergone then it will be so problematic and hard to recover. This process 
lacks automation ana laterality. Here will present a novel method that uses model checking and inductive 
learning, is us^fcTaetect and correct the incompleteness of a specified set of operational requirements 
with respect^^^oals. The particular inductive learning technique we use called Inductive Logic 
Programmi^^nCP), Prolog, is given with background knowledge, positive scenarios, negative scenarios are 
declarat^yW^expressed in temporal logic. The practice of temporal formalism permits computerized 
inves|r^|ioTi and tool enhancement. This makes use of existing knowledge base during inference process. 
vfJe^Wierit of this process is inevitably ensures the reliability of well-read requirements with respect to the 
^takejiolders goals. 

The projected frame is an iterative procedure involves four segments: In behavior analysis phase, the partial 
operational specification will be tested against stakeholders goal using Labeled transition system analyzer. 
If any abnormalities are detected, then desirable and undesirable behaviors will be drawn in the scenario 
elicitation phase. In the requirement sugges - tion phase, goals, partial operational specification, positive 
and negative scenarios are used by the prolog system, to compute the operational requirements that 
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guarantees the goal. If the learner creates another set of operational requirements, the manual intervention 
is required to rate the appropriate requirement that fit for the system function. 

A. Problem Statement 

The complications in developing operational requirement specification is the expansion of operational 
requirement that assurances the goals fulfillment. When this process is done manually it leads to time 
consumption, expensive and error prone. Stakeholders chooses to express their goal through narrative style 
rather than declaratively in temporal manner, because the scenarios are partial descriptions about ♦gasirrV 
behavior so it may omit some desired behavior. When the requirements are elicited from scenario-^^d 
description is tiresome, and bugs-prone practice, it depends on labor-intensive approach, it can ]j^£t<from 
automated approach. 

When the process is done manually, they are less accessible to the practitioners. UseAdDecohie frustrated 
when the software not meets their needs. Customers who pay for the system map^li to pay for the 
mistakes, when the same system is developed for more than one organization, siroftaT^ifort have to repeat 
for every system development. It consumes time and expensive process. ✓V^? 

The earlier approaches for requirements elaboration requires more timpani c*>st. Because of fully manual 
approach, there is likely for the introduction of errors. Lack in the exacu^l^f any of the process will leads 
to development problem, it is more expensive to repair. 



B. Objective of The 




Requirement engineering encompasses various activities f(jS^%oal elicitation to requirement management. 
Requirement elicitation is the process of eliciting M^irements from the stakeholders, Requirement 
specification is the process of specifying the requir^i^pts to satisfy the stakeholders goal, Requirement 
analysis is the process of verifying whether the orjN^jional requirements satisfies the goal. Requirements 
are defined at the earlier stage of software developrrent as a de - scription of what should be implemented. 
The objective is to create an operational jjpCn%:ation that is assured to fulfill the goals. The tool-based 
framework is used to combine model ^Jis^ahg and inductive learning approach. The model checking 
technique is used to check for deviation} and inductive learning is used to resolve it. The well-read 
requirements from the learning syl^^are guaranteed to cover all the desirable behaviors and eliminate 
negative scenarios. 



syj(^^a 

v {/} II. EXISTING SYSTEM 



Goal based requirern^ffl«(fTgineering denotes the usage of goals for requirement elicitation, expansion, 
organization, desaagmy; exploration, negotiation, assignment, documentation, and evolution. One of the 
major complicitia«sJh producing a system specification is the elaboration of operational requirements that 
assurances th^^lfillment of the goals. When the process of detecting incompleteness and resolving it, is 
done manu\r)yit leads to erroneous operation. This is principally labor-intensive task and hence is pricey 
and bua^Swie. Very little methodical, laborious support exist, however such methods lacking in required 
c l^r acteVstics such as computerization or generalization, making them less accessible to practitioners. This 
^^^^cHnvestigators to search for rigorous and automatic methods to support the fulfillment of these tasks. 

C. Demerits of Existing System 

Consumption of more time: If the same system is established for more than one organization, similar 
efforts have to re - appear for every system development. It leads to more time consumption. 

Expensive: When the requirement elaboration process is done manually, it requires more man power, so it 
is costlier process. 
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Inaccuracy: There is more human contribution in the manual process, so there is a possibility of likely to 
have bugs. 

III. Proposed System 

The projected system will present a innovative approach that uses labeled transition system analyzer as 
model checker and prolog as inductive learner to identify and resolve incompleteness in the operational 
requirement specification with re - spect to goal. . The Labeled transition system analyzer legally validates 
the fulfillment of the goals and generates counterexamples when incompleteness in the opemtifcrS^ 
requirements are found. The prolog system then pick-out operational requirements frorrv^Vie 
counterexamples and user-provided positive examples. These well-read requirements from th^Lyftiing 
system are surefire to entail all the desired behavior and none of the undesired ones. This pri9fc*ns done 
iteratively till on no account of goal ruin is discovered. t^f^ 

D. Merits of Proposed System 





fSpjJTr^^ve 



Less time procedure: The same tool can be recommended for the related sys^rTr^^velopment in various 
organization. 

Limited budget: when tool-based methodology is used there will be^e^^^li power , so that price will be 
reduced. 

Reduced error: Because of less labor-intensive, there is a p( 

IV. Proposed Systj 
E. Anah 



The analysis part, is concerned with inevitably**xamining whether a given incomplete operational 
specification entails Fluent Linear Tempor^I^gic (FLTL) property, may be safety property or progress 
property. 



The Labeled Transition System An^^srTLTSA) is first used to build Labeled Transition System (LTS) from 
incomplete operational specificMion WBth respect to fluent description. Labeled transition system is verified 
against goal, its result will be effheW violation or no violation. The particular event should not have occurred 
at a particular situation. If qrf^Srrfrom initial state to error state, it destructs the safety property. The trace 
does not reaches the err^rOwTC, it satisfies the safety property. Labeled transition system analyzer checks 
for all terminals in LaJpsp^fransition system. If anyone terminals in the event has not look as if, then LTSA 
is said to disrupt.^ ^jrogress property. The discovery of a destruction trace indicates a absence of 
requirement fc\s%mj software-controlled event happening or not happening within the last time unit and 



hence an incgMj^teness in the present operational specification. 

F. Scenario Elicitation Phase 

f^Mfrm the condition on events whose existence or nonexistence in the counterexample indicates to goal 
stoiction. The motive is to yield a result that is applicable to certain problem. The engineer asked to 
provide positive and negative scenario that illustrates good and bad system behavior. The human 
intervention is required to detect the event that must not have happened at a certain situation in the trace, 
that is called negative scenario. The manual-intervention is essential to find the event that should occur at a 
Specific situation in the trace that is called positive scenario. 

As a result the positive and negative scenarios will be elicited. 
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G. Requirement Suggestion Phase 

The incomplete specification, goals, set of fluent definition, elaborated positive and negative scenarios are 
given as input to the learning system. The result of this level is set of operational requirements, describes an 
Labeled transition system that admits all the optimistic scenarios and none of the undesirable scenario. 

By using Inductive logic programming, we will be provided with the alternative set of requirements. 

Prolog System 

Machine learning, is the process of constructing a system that can learn from data given by user, ^kh»uses 
logic programming as a uniform representation for examples, background knowledge and hypan^esiaf Given 
an encoding of above, Prolog system will develop an theorized logic program which ^qtores all the 
optimistic examples and none of the undesirable examples. The prolog system wilCjpe gWen with the 
knowledge bases, then it will compute all well-read operational requirements, that aa«|ra^ail the desirable 
scenarios and none of the undesirable scenarios. >» 

H. Requirement Selection Phase (j 

Manual Process: 

When the learner produces the alternative set of requirements, the^«ir-intensive is vital to handpick the 
requirement that fits the system's functionality. The intention befijjr^vhy only one set is nominated is that, 
although each set of wellread theories is reliable with the background and elucidates the illustrations, the 
learning does not assures reliability between the alternatfc«pfanations computed in a single iteration, 
henceforth selecting numerous explanations at once mavtopwlidate truthfulness given in the program. The 
Labeled transition system model produced from li^ffl^shly stretched description does not agree the 
undesirable situation elaborated in the preceding r^Aand agrees all the optimistic scenarios. 

The learning system recognizes common umjBflted properties from the negative scenarios. 

» ^^ystem Architecture 



it aMii 



The projected system will preset an^m>vative technique that uses model checker and inductive learner to 
identify and resolve incompletamss in the operational requirement specification with respect to goal. . The 
LTSA legally validates the JayHarent of the goals and creates counterexamples when partialness in the 
operational requirementas^jjlcted. The prolog process then generates operational requirements from the 
counterexamples and hifci^-provided positive examples. These well-read requirements from the learning 
system are assured ti^mis all the optimistic scenarios and none of the adverse scenarios. This practice is 
done iterativeb^tij^^ goal destruction is detected. 

I. Step i. Analysis Phase 

lecker is first used to build an Labeled Transition System from a incomplete description with 
explanations . It is then used to validate the LTS in contrast to the goals . The result of the 
iah^is phase is moreover a report that no destruction traces have discovered, in which case the procedure 
sullressfully ends, or that a counterexample has detected, in which case it is displayed. The recognition of 
destruction trace indicates absence of operational requirements. 

J. Step 2. Scenario Elicitation Phase 

If destruction is detected in the analysis phase, then the engineer needs to elicit positive and negative 
scenarios that illustrates good and bad behavior of the system. A negative scenario represents an event that 
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must not have happened at certain situation. A positive scenario represents an event that must have 
happened at specific situation in the trace. 

As a result, the desirable and undesirable behavior will be elicited. 



K. Step 3. Requirement Suggestion Phase 

Prolog technique is process used to derive hypothesized logic program that entails all the positive scenarios 
and none of the negative scenario. 

The knowledge bases, goals, partial operational specification, fluent definitions, and 
translated into a logic program and given to an Prolog system. The result of this level is either/pfe^ false . 
which will be decided based upon the conditions was given by user, each of which permit^HUre positive 
scenarios, forbids all the negative ones, and is consistent with the goals and thi 
specification 



L. Step 4. Requirement Selection Phase 




e^MO# a: 

operational 



The conditions will be provided with the prolog system, then this w 
desired behavior, or not. If the conditions given by the user agrees wit 
scenarios, goals, then it will provide result as true. Otherwise If the 
agrees with the background knowledge then it will provide false, 
requirements manually, and make the requirements correct. 




i^l^itec^ whether it admits all the 
SjJS^a^ckground knowledge, positive 
' mions given by the user does not 
is we have to pick out the missing 



Alternate set of operational 
requirements 





Goal ^ 




t 




Prolog sys- 
tem 





Consistent and assured op- 
eiaiional requirements 



D-sired be- 
havior 



Figure 1. System Architecture Diagram 
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Figure 4. Requirement Suggestion from 
Prolog 

VII. Conclusion 

Requirement elicitation and elaboration is 
the most important task in requirement 
engineering. Our focus in this paper is the 
elaboration of incomplete opes^ifcnaV 
requirement specification by usingN^il 
based approach. We have see^Jl^t the 
process of systematicall^^tfflanging 
requirements specificaticir^^can be 
supported by the corfoinaSon of model 
checking and Proloapii^Saing are applied 
respectively. It^^N^ndes automated, 
formal supMtr^For analyzing the 
incomplete operational requirements and completing it with respect to g^^. The model checking 
technique is used for detecting the incomplete requirements and Logi^^i^igramming is used in prolog 
system for automatically generating the missing requirements tha 
requirements are generated automatically guaranteed to satisfy th 
fulfill the operational requirement effectively related with fully lal 



■ r ■ 



.^S^Mmsistent with the goals. Any 
^ffl^So this novel method is used to 
nsive approach. 



VIII. Future 



For the future, the learning system should be developed^itxT the newer techniques to identify and resolve 
the incompleteness. This method uses Prolog systefir^ji complete the operational requirements, for the 
future we can use improved and efficient J^^Hng technique to automatically generate missing 
requirements and to improve the completeness in tfte requirements. 
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